下午的交接會議裡，一位新接手的人問內部 Agent：

「這張工作單現在是 Pending。照我們的流程，什麼條件下可以進 In Progress？」

這是一個很普通的規則問題。

Agent 查到目前 Workflow，也找到對應的 Transition 條件。

它先回答：

必要資料完整、前置核准完成後，可以進入 In Progress。

接著畫面又多了一行：

Update completed.
Current status: In Progress

使用者愣了一下。

「我是在問規則，沒有叫你改。」

API 沒有失敗。

Target 也沒有找錯。

狀態真的被更新了。

真正越界的是另一件事：

Agent 把「我知道這件事怎麼做」，直接升級成「我現在可以替你做」。

Knowledge 和 Action 是兩種不同能力

對人來說，這個差別通常很自然。

你問同事：

這個欄位怎麼改？

他可以告訴你規則、步驟和前置條件。

但不代表他下一秒就登入正式系統幫你改掉。

AI 接上 Tool 之後，這條線比較容易消失。

因為同一個 Agent 可能同時知道：

• 規則是什麼
• API 怎麼呼叫
• Target 在哪裡
• 自己也有 Write Tool

從技術能力看，答案和動作只差一個 Tool Call。

從工作責任看，卻是兩種 Capability。

Package 裡因此直接拆開：

Knowledge
≠
Action

Knowledge 負責回答規則、Schema、Query 語意與操作方式。

Action 才負責正式 Read / Write。

能做，不代表這次請求是在叫你做

很多 Agent Demo 喜歡展示一件事：

使用者一句話，系統自己一路做完。

這確實方便。

但如果 Knowledge Request 也能在沒有明確轉換的情況下進入 Action，使用者就無法知道什麼時候自己只是詢問，什麼時候已經授權正式修改。

真正需要的不是「每次 Write 都再問一次 Yes / No」。

而是 Capability Boundary。

例如：

Knowledge path
- explain
- inspect rules
- describe required inputs

Action path
- query live object
- create / modify / delete
- trigger external operation

當使用者只進到 Knowledge Path，系統就不應因為「反正我也會做」而自行升級成 Action。

分開之後，Agent 沒有變回聊天機器人

如果使用者說：

幫我把這張切到 In Progress。

那就是 Action Request。

系統可以直接走 Write Path。

但如果他問：

什麼條件下可以切到 In Progress？

就停在 Knowledge。

差別不是模型有沒有能力完成工作。

而是使用者這一次把哪一種能力交給了它。

Knowledge 可以很完整。

甚至可以先把需要的 Target、前置條件和可能結果說清楚。

但真正改變正式 State，仍然要從 Action Request 開始。

後來，規則問題只回規則

幾天後又有人問：

「這個頁面的 Owner 要怎麼換？」

Agent 查完後回：

Current rule:
Owner can be changed through the update action.

Required input:
- target page
- new owner

然後停下來。

使用者看完，補了一句：

「好，那現在幫我改成 Alex。」

這時才進 Action Path。

同一支 Agent 還是會查，也還是會改。

只是它不再把兩種能力混成同一件事：

我知道怎麼做。

和：

你現在要我做。